Alteryx Serverってなあに : アーキテクチャ編
こんにちは、小澤です。
本エントリは2020年アドベントカレンダー『今日からはじめるAlteryx再入門』の22日目のエントリです。
「アーキテクチャ」、なにやら難しい話っぽいですね。
Alteryxでワークフローを動かす環境はDesignerもあれば、Serverもあります。 また、どんなデータをどこから取ってきどこに出力するのかも様々です。 そんな様々な要素がそれぞれどうなっているのか、紐解いていきましょう。
まずは基本的な動きから
Alteryxを使う上で最低限必要なものは以下になります。
- ワークフローの作成環境
- 処理内容が記述されたワークフロー
- 処理を行うエンジン
- ワークフローをエンジンに渡して実行する仕掛け
普段使う分にはあまり意識しなくても問題ありませんが、Alteryx Designerはワークフローの作成とエンジン実行のトリガーの役割をはたしているわけです。 実際、ワークフローの実体はXMLファイルなのでDesigner以外の環境でもやろうと思えば作成や編集が可能ですし、アドオンの追加でDesignerを介さずにコマンドからの実行することも可能です。
- bigangryguy/pyx (Alteryxのワークフローを作成するPythonライブラリ)
- Alteryxのワークフローをコマンドラインから実行する #alteryx #22 | Alteryx Advent Calendar 2016 | Developers.IO
なんか難しそうですがとりあえず
- ワークフローのファイルはどんな処理をするかの手順が書かれている
- エンジンはワークフローとして書かれた手順に基づいて処理を実行するもの
- エンジンにたいして「このワークフロー実行しといて」と指示する役割が必要
ということだけ覚えておけば問題ありません。
Alteryx Serverにおける構成
さて、なぜ上記3つを覚えておけばいいかというと、Alteryx Serverの構成に関わる仕組みとなるからです。 Alteryx Serverは以下の要素で成り立っています。
- ギャラリー
- スケジューラ
- データベース
- ワーカー
何やら色々な要素が出てきましたね。 これらは複数人が同時にワークフローを実行する可能性があるという、Alteryx Serverの性質をよく表している構成となっています。
Alteryx Serverを既に利用している方であれば、ギャラリーやスケジューラの存在は見たことがあるでしょう。 ギャラリーでは、Designerで作ったワークフローをServerに保存したり、Collectionを使って他の人と共有したりといった設定が行えます。
ギャラリーではRunボタンから、スケジューラでは指定したに日時になったらワークフローの実行が行えます。 しかし、これらはギャラリーやスケジューラ自体がワークフローを実行しているわけではありません。
ワークフローの実行は全てワーカーで行われます。 前述のエンジンがインストールされ、ワークフローの実行ができるコンポーネントがワーカーとなるわけです。
ユーザから利用されるインターフェースとワークフローを実行する環境が分かれているため、それらの間のやり取りをする仕組みが必要になります。 そのためのコンポーネントがコントローラとなります。
ワークフローの保存やスケジュールの登録、実行などの制御を行うのはコントローラの役目となり、 それらに必要な情報をデータベースに保存しておくわけです。
具体的な流れとしては
- Designerで作成したワークフローをServerに保存する
- Server側で受け取ったワークフローは、コントローラを経由してデータベースに保存される
- 保存されたワークフローギャラリー上からワークフローを実行
- コントローラが実行したいという情報を受け取りデータベースからワークフローを取得
- コントローラ上のキューにワークフローを実行したいという情報を入れておく
- ワーカーがコントローラのキューからその情報を取得してワークフローを実行
- 実行結果をコントローラ経由でデータベースに格納
といった流れになります。 何事もコントローラを経由して、それぞれが自分の役割を果たすように分担されているわけです。
なぜ、このようないろんな要素が絡み合う仕組みにしているのでしょうか？ その理由はServerのスケールアウトや可用性の向上が目的となります。
特に意識しなければ、1台のサーバに全てのコンポーネントをまとめてインストールできますが、 コンポーネント単位でそれぞれ別環境にインストールすることも可能です。
例えば、ワーカーを別環境に分けつつ複数台用意すればコントローラのキューにあるワークフローを手の空いているノードが実行するということも可能です。 これによって、複数人で同時にワークフローを実行する際にスケールさせれると同時にどこかが落ちても全体での動作は止まらない仕組みも実現します。 ギャラリーについても、同様にロードバランサ配下に複数台設置できます。 データベースに関してはMongoDBを利用しているので、Alteryx固有の特別なものではなく、通常のMongoDBを用意してスケールさせればいいだけとなっています。
このようにAlteryx Serverでは複数人が同時にアクセスして同時にワークフローを実行する前提でそれらを滞りなく順番に実行でいる仕組みと、 その数が増えたときにスケールアウトさせて処理速度を維持する仕組みが用意されています。
単一サーバでもスケールアップによって同時実行数を増やすなども可能ですが、単一サーバーでは性能の限界もありますし可用性の問題もあるため、 利用者が増えてきたら、スケールアウトも検討するといいでしょう。
Alteryx Serverでのワークフローの実行とアセットの扱い
Alteryx Serverでは、ワークフローを含めて全てのデータがデータベースであるMongoDBに格納されています。 続いては、どのように保存されて、どのように実行されるのかを確認してきます。
Alteryx Serverではワークフローは全てyxzpという圧縮された形式で保存されます。
ワークフローをyxzpファイルでパッケージングすると、入出力で扱うデータなども含めて単一のファイルとなります。 Input/Output Dataツールなどで設定しているファイルパスを相対パスに変更してワークフローとセットでzip形式に圧縮したものがyxzpファイルとなります。
Alteryx Serverでは、ワークフロー実行時にデータベースからこのファイルを取り出して、一時フォルダに解凍します。 入力で利用するファイルは解凍した中身に含まれており、相対パスになっているためそのまま実行可能というわけです。 実行後は出力されたファイルがデータベースに格納され、一時フォルダは削除されます。 Resultsに表示されるログなどは設定していれば別途保存されますが、基本的にはデータベースに格納された出力以外の実行結果は何も残りません。
yxzpファイルにどんな別ファイルを含めるかはアセットで指定可能です。 この仕組みによって、入出力のどちらかを含めなかったり、別なファイルを含めたりといったことが可能になります。 入出力ファイルをアセットに含めなかった場合、それらはファイルパスがyxzp内での利用に応じた相対パスに変換されることもありません。 この動きに関しては以下をご参照ください。
アセットには入出力ファイルの他、マクロを使って独自で作成したツールも含まれます。 ツールを独自で作成している場合、通常であれば環境ごとに入れておく必要があります。 これは、Alteryx Server上で実行する場合も同様で、特にワーカーが複数あるような場合にはそれぞれにインストールしておく必要があります。 独自で作成したマクロをアセットとして含めてしまえば、他からは参照できないものの、そのワークフローからであればServer側で特別な設定をしなくても実行できます。
なお、以下に含まれるマクロに関してはデフォルトではアセットに含まれないのでご注意ください。
- Alteryxインストール時に含まれる標準ツールでマクロで実装されているもの
- User Settignsにて、マクロの読み込み先フォルダとして指定しているもの
これらに関しては、ワークフローをアップロードする際にアセットの設定で明示的にチェックを入れる必要があります。
Data ConnectionsとAlteryx Designerでの利用
最後にAlteryx Serverで利用可能なData Connectionsの仕様について確認します。
Alteryx ServerではAdmin画面にてData Connectionsの設定が可能で、 Designerからそれを利用して、外部のデータベースへの接続が可能です(※ Alteryx Serverのアーキテクチャに含まれるデータベースではなく利用するデータの格納先としてデータベース)。
この際注意が必要なのは、Serverでの設定はあくまでも接続先情報を設定しておくものです。 Designerから利用する際にServerを介してデータを取得や保存をしに行くわけではありません。
これはどういうことかというと、まずDesignerであるかServerであるかに関わらずワークフロー実行時にデータベースに接続するためにはODBCドライバを利用しています。 ODBCドライバはそれぞれのデータベースに接続詞に行くためのもので、データベースごとに存在個別のドライバが存在ます。 これはMySQLでMySQL用のドライバ、PostgreSQLでPostgreSQL用のドライバ、RedshiftであればRedshift用のドライバ...のように実際に利用するデータベースごとのドライバとなります。 それぞれ異なるものであるため、接続しに行く環境ごとにAlteryxとは別にインストールしておく必要があります。
また、それぞれのドライバがデータベースに接続するには、データベースのURLやユーザ名・パスワードなどの情報が必要になります。 これらの接続先に関する情報は、Input Dataツールなどで直接記述することも可能ですが、DSNの設定をしておくことも可能です。 DSNでの設定は、Alteryxに関わらずPC内全体で共通して使えるように別名を定義しておき、ここのプログラムはそれを利用するような仕組みとなっています。
Alteryx Designerでは、ツールの設置値として接続先を直接している場合は全て直接入力する必要がある一方、 DSNを利用する場合は設定されているものリストから選択できるようになっているため、ほとんどの場合DSNを利用していると思われます。 DSNの設定はPCごとに行うため、データベースに接続するワークフローを動かす全ての環境で以下の設定がされている必要があります。
- ODBCドライバのインストール
- 同一のDSN名で同一の接続先情報
前者は比較的分かりやすいのですが、DSNの設定でうまくいかないパターンが時々あります。 個々人の環境での設定となるため全体一律で設定と言うのがしづらく、人によってスペースが入っていたり微妙にtypoしていたりなどでうまくいかなかっりします。 また、人によっては別な環境へ接続するためにその名称は既に利用しているなどの問題も起こりがちです。
こうした、個別でDSN設定をしなければならない問題を解消するための仕組みがAlteryx ServerでのData Connectionsの設定となります。 ここで設定さえた値は、共通のDSNのような役割を果たします。 Serverで設定された接続先の名称一覧から必要なものを選択することで、誰でも共通で同じ名称で同じ接続先が実現できるというわけです。 ただし、あくまでも実際にデータベースへの接続を行うのはワークフローを実行している環境となるため、ODBCのインストールはそれぞれの環境で行う必要あるわけです。
おわりに
今回は、「Alteryx Serverってなあに : アーキテクチャ編」ということで、 Alteryx Serverが内部でどのような動きをしているのかと、Designerと共通して動かせるワークフローの設定の話をしました。 "必要になった時だけ"思い出す程度でも困らないとは思いますが、必要なった際にぜひ参考にしていただければと思います。
明日はshoによる『Alteryx Serverってなあに : 運用編』の予定です。 お楽しみに！
